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DETAILED ACTION 

This is a first Office action on the merits of this application. Claims 1-22 
are presented for examination. 



Specification 

1 . The disclosure is objected to because of the following informalities: the 
status of related cases mentioned in the specification (see p. 1 1, line 10, for 
example) must be updated. 



Claim Objections 

2. Claims 1 and 1 1 are objected to because of the following informalities: 
In claim 1 , the phrase "roles to implemented" on line 6 contains a 

grammatical error. Perhaps it should read "roles to be implemented." 
In claim 1 1, the phrase "a plurality of configuration entities further 

comprises," on line 2 of the claim is redundant, and should be deleted. 
Appropriate correction is required. 



Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for 
all obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described 
as set forth in section 102 of this title, if the differences between the subject matter sought to 
be patented and the prior art are such that the subject matter as a whole would have been 
obvious at the time the invention was made to a person having ordinary skill in the art to which 
said subject matter pertains. Patentability shall not be negatived by the manner in which the 
invention was made. 
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3. Claims 1-22 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Zager et al. (U.S. Patent No. 6,393,386, hereinafter "Zager"), in view of 
Bhaskaran (U.S. Patent No. 6,266,335). 

In considering all of Applicant's claims, note that the claims are directed 
toward a network model for modeling a network. Note that the Zager reference 
teaches a network modeling system including various network elements, but not 
every known network element. Nonetheless, it would be obvious to a person 
having ordinary skill in the networking art to include any known network element 
in the network modeling system taught by Zager, so that the network model can 
be up to date by including the latest technologies, and can thus be as accurate 
as possible. 

In considering claim 1 , Zager discloses a configuration data model 
("model") for relating configuration objects of a computer network to other 
configuration objects, and for expressing the configuration objects of a computer 
network in a form accessible by other network components (col. 5, lines 63-67; 
col. 6, lines 1-28), comprising: 

Device role IP post entities that represent software roles to be 
implemented on specific network device IP hosts (col. 22, lines 50-61 , wherein 
the "IP service consumer application" on a particular computer node is modeled); 

IPs entities that represent IP addresses associated with devices on a 
network (col. 10, lines 23-50; col. 22, lines 50-61); 
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Status entities that represent the status of various software and hardware 
elements of a computer network (col. 6, lines 62-67, "change of state"; col. 7, 
lines 19-30, "events" and "alarms"); and 

Device entities that represent specific devices on a network (col. 6, lines 
15-18, 24-48, "hub, router, computer, ..."). 

Although Zager discloses numerous entities that can be part of the 
network model, including IPs entities as discussed above, Zager does not 
specifically disclose that the IPs entities are virtual IPs entities. Nonetheless, the 
use of virtual IPs entities in a computer network is well known, as evidenced by 
Bhaskaran. In a similar art, Bhaskaran discloses a network including hardware, 
software, IP entities, and devices, wherein the IP entities are virtual IP entities 
(Abstract, col. 1 , lines 47-67, describing a "virtual IP" server system). Given the 
teaching of Bhaskaran, a person having ordinary skill in the art would have 
readily recognized the desirability and advantages of including virtual IPs entities 
in the network model taught by Zager, to allow for a more flexible and accurate 
model of the network system that can include all known network devices. 
Therefore, it would have been obvious to include virtual IPs entities taught by 
Bhaskaran as part of the model in the system taught by Zager. 

In considering claim 2, Bhaskaran further discloses that the network may 
include encryption and other security measures (col. 2, lines 43-65). However, 
the system taught by Bhaskaran and Zager does not teach that a firewall conduit 
entity is necessarily included in the model system. Nonetheless, Examiner takes 
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official notice that the use of a firewall is a well known network practice used to 
increase security of network communications. Thus, given the knowledge that 
Bhaskaran includes security measures in its network system, and given the 
common knowledge of the use of firewalls in a network environment, a person 
having ordinary skill in the art would have readily recognized the desirability and 
advantages of including a conduit firewall entity in the model system of Zager 
and Bhaskaran to allow for a more flexible and accurate model of the network 
system that can include all known network devices. Therefore, it would have 
been obvious to additionally include the firewall conduit entities taught by 
Bhaskaran as part of the model in the system taught by Zager. 



In considering claim 3, Zager further discloses device role configuration 
entities that specify the configuration of various software roles to be implemented 
on devices connected to a network (col. 6, lines 12-34; col. 12, lines 23-40, 
wherein configuration changes for system resources are implemented in the 
model). 



In considering claim 4, Zager further discloses device role configuration 
values that define specific types of device role configurations that may be 
contained by the device role configuration entities (col. 19, lines 12-15, 51-54; 
col. 22, lines 62-67; col. 23, lines 1-6, describing configuration of various devices 
with different roles, wherein the configuration values are necessarily part of the 
configurations). 
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In considering claim 5, Zager further discloses role configurations entities 
that define the configuration associated with software roles of devices on a 
network (col. 6, lines 12-28; col. 19, lines 12-15, 51-54; col. 22, lines 62-67; col. 
23, lines 1-6, describing configuration of various devices and software with 
different roles). 

In considering claim 6, Zager discloses a configuration data model for 
relating information regarding the configuration of various software, network, and 
hardware entities on a computer network, comprising: 

Role configurations entities, device role configuration entities, and device 
role IP host entities that define the configuration of various software roles of 
devices and applications used on a computer network (col. 22, lines 50-61, 
wherein the "IP service consumer application" on a particular computer node is 
modeled; col. 6, lines 15-18, 24-48, "hub, router, computer, ..."); 

Status entities for monitoring the status of various software and hardware 
elements of the computer network (col. 6, lines 62-67, "change of state"; col. 7, 
lines 19-30, "events" and "alarms"); and 

IPs entities that relate to IP addresses to be used by devices connected to 
a network (col. 10, lines 23-50; col. 22, lines 50-61). 

Although Zager discloses numerous entities that can be part of the 
network model, including IPs entities as discussed above, Zager does not 
specifically disclose that the IPs entities are virtual IPs entities. Nonetheless, the 
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use of virtual IPs entities in a computer network is well known, as evidenced by 
Bhaskaran. In a similar art, Bhaskaran discloses a network including hardware, 
software, IP entities, and devices, wherein the IP entities are virtual IP entities 
(Abstract, col. 1 , lines 47-67, describing a "virtual IP" server system). Given the 
teaching of Bhaskaran, a person having ordinary skill in the art would have 
readily recognized the desirability and advantages of including virtual IPs entities 
in the network model taught by Zager, to allow for a more flexible and accurate 
model of the network system that can include all known network devices. 
Therefore, it would have been obvious to include virtual IPs entities taught by 
Bhaskaran as part of the model in the system taught by Zager. 

In considering claim 7, the combined teaching of Zager and Bhaskaran 
further discloses that the virtual IPs entities relate to device entities representing 
specific devices connected to a network, and act as a buffer between the network 
and the devices represented by the device entities (Zager, col. 22, lines 50-61 , 
describing the IP addresses assigned to certain network devices; Bhaskaran, col. 
1 , lines 47-67, describing that the virtual IP connections occur between the 
network and the destination servers, and therefore act as a buffer between the 
two systems). 

In considering claim 8, Zager discloses a computer readable set of 
instructions residing on a computer-readable medium that produces a software 
data model comprising: 
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Device role IP host entities (col. 10, lines 23-42, ""IP network protocol MO 
on the database server's node offers networkAccess services"); 

Role configuration entities and device role configuration entities (col. 8, 
lines 22-41, wherein the devices have certain roles - i.e. computers, hubs, 
printers, and routers - and have different configurations); and 

Status entities (col. 6, lines 62-67, "change of state"; col. 7, lines 19-30, 
"events" and "alarms"); 

Wherein device role IP host entities, role configuration entities, and device 
role configuration entities each relate to software roles that comprise multiple 
software packages to be installed on various devices connected to a network 
(col. 6, lines 12-28, describing the various software entities; col. 35, lines 32-50, 
wherein the manager selects a bundle to implement a service); and 

Wherein said status entities monitor the status of hardware devices and 
software applications used on the network (col. 1 1 , lines 17-45, "faults, states, 
events..."). 

However, Zager does not disclose virtual IPs entities wherein the virtual 
IPs entities relate to device entities representing specific devices and provide 
virtual IP addresses for the devices represented by the device entities to the 
various other devices using the computer network. Nonetheless, the use of 
virtual IPs entities in a computer network is well known, as evidenced by 
Bhaskaran. In a similar art, Bhaskaran discloses a network including hardware, 
software, IP entities, and devices, wherein the IP entities are virtual IP entities 
that represent specific devices (i.e. servers) to other devices on the network 
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(Abstract, col. 1 , lines 47-67, describing a "virtual IP" server system). Given the 
teaching of Bhaskaran, a person having ordinary skill in the art would have 
readily recognized the desirability and advantages of including virtual IPs entities 
in the network model taught by Zager, to allow for a more flexible and accurate 
model of the network system that can include all known network devices. 
Therefore, it would have been obvious to include virtual IPs entities taught by 
Bhaskaran as part of the model in the system taught by Zager. 



In considering claim 9, Zager discloses a configuration data model for 
characterizing the configuration of all software and hardware elements connected 
to a network (col. 3, lines 4-1 1 , "model, not only the significant hardware and 
software resources of the system being administered, but also the service 
relationships connecting those resources"), comprising: 

A plurality of device entities (col. 6, lines 15-17, "hardware" components); 

A plurality of conduit entities (col. 6, lines 17-18, "hub, router,..."); 

A plurality of device role IP host entities (col. 10, lines 23-42, ""IP network 
protocol MO on the database server's node offers networkAccess services"); 

A plurality of interface IP type entities (wherein hubs and routers are 
interfaces to the network); 

A plurality of services entities (col. 10, lines 23-42, "networkAccess 
services"); 
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A plurality of role configurations entities and device role configurations 
entities (col. 8, lines 22-41 , wherein the devices have certain roles - i.e. 
computers, hubs, printers, and routers - and have different configurations); 

A plurality of status entities (col. 1 1 , lines 17-45, "faults, states, events..."); 

A plurality of component type entities (col. 6, lines 15-17, "hardware and 
software components"); and 

A plurality of device role configuration values entities (i.e. the 
configurations will necessarily be set to some value). 

Although the system taught by Zager discloses all of these entities, 
including IP entities as discussed above, Zager does not specifically disclose that 
the IP entities are virtual IPs entities. Nonetheless, the use of virtual IPs entities 
in a computer network is well known, as evidenced by Bhaskaran. In a similar 
art, Bhaskaran discloses a network including hardware, software, IP entities, and 
devices, wherein the IP entities are virtual IP entities (Abstract, col. 1 , lines 47- 
67, describing a "virtual IP" server system). Given the teaching of Bhaskaran, a 
person having ordinary skill in the art would have readily recognized the 
desirability and advantages of including virtual IPs entities in the network model 
taught by Zager, to allow for a more flexible and accurate model of the network 
system that can include all known network devices. Therefore, it would have 
been obvious to include virtual IPs entities taught by Bhaskaran as part of the 
model in the system taught by Zager. 
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In considering claim 10, although the system taught by Zager and 
Bhaskaran discloses substantial features of the claimed invention, it remains 
silent regarding the manufacturing model of the network entities. Nonetheless, 
any network will have devices of certain manufacturing models. Thus, it would 
have been obvious to a person having ordinary skill in the art to include these 
manufacturing models as part of the extensive network model taught by Zager, to 
better estimate the performance of the network, especially when it is a 
heterogeneous network like the Internet. 



In considering claim 1 1 , Zager further discloses that the plurality of 
configuration entities further comprises a plurality of component objects entities 
("managed object," col. 8, lines 51-67). 



In considering claim 12, Zager further discloses a plurality of device roles 
history entities ("interaction history," col. 15, lines 50-63). 

In considering claim 13, Bhaskaran further discloses that the network may 
include encryption and other security measures (col. 2, lines 43-65). However, 
the system taught by Bhaskaran and Zager does not teach that a firewall conduit 
entity is necessarily included in the model system. Nonetheless, Examiner takes 
official notice that the use of a firewall having communications portholes is a well 
known network practice used to increase security of network communications. 
Thus, given the knowledge that Bhaskaran includes security measures in its 
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network system, and given the common knowledge of the use of firewalls in a 
network environment, a person having ordinary skill in the art would have readily 
recognized the desirability and advantages of including a conduit firewall entity in 
the model system of Zager and Bhaskaran to allow for a more flexible and 
accurate model of the network system that can include all known network 
devices. Therefore, it would have been obvious to additionally include the 
firewall conduit entities taught by Bhaskaran as part of the model in the system 
taught by Zager. 

In further considering this claim, Zager further discloses that the model 
includes the entities' relationships to each other (col. 6, lines 25-27, "this model 
represents the various components, relevant subcomponents, and their service 
relationships to each other"), and further discloses that the entities may be 
related to each other according to one-to-many and many-to-one relationships 
(col. 29, lines 46-61 , "relationship types have the following attributes... one-to- 
many... many-to-one"). Although the system taught by Zager does not explicitly 
describe the entity-by-entity relationships claimed, it nonetheless suggests, in 
cols. 6 and 29, that entities can have any type of relationship to other entities. 
Thus, it would have been obvious to a person having ordinary skill in the art to 
include the specific many-to-one relationship mentioned in the claim to the 
system taught by Zager, to allow for a more flexible and accurate model of the 
network system. 
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In considering claim 14, Zager further discloses that the device role IP 
host entities relates an IP host address to a device role (col. 10, lines 23-60, 
wherein the model includes the paths to specific IP hosts). 

In further considering this claim, Zager further discloses that the model 
includes the entities 7 relationships to each other (col. 6, lines 25-27, "this model 
represents the various components, relevant subcomponents, and their service 
relationships to each other"), and further discloses that the entities may be 
related to each other according to one-to-many and many-to-one relationships 
(col. 29, lines 46-61, "relationship types have the following attributes... one-to- 
many... many-to-one"). Although the system taught by Zager does not explicitly 
describe the entity-by-entity relationships claimed, it nonetheless suggests, in 
cols. 6 and 29, that entities can have any type of relationship to other entities. 
Thus, it would have been obvious to a person having ordinary skill in the art to 
include the specific many-to-one relationships mentioned in the claim to the 
system taught by Zager, to allow for a more flexible and accurate model of the 
network system. 



In considering claim 15, Zager further discloses that the interface IP type 
entities represent allowed types of IP addresses within the network (col. 27, lines 
30-65, "domain name services"). 

In further considering this claim, Zager further discloses that the model 
includes the entities' relationships to each other (col. 6, lines 25-27, "this model 
represents the various components, relevant subcomponents, and their service 
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relationships to each other"), and further discloses that the entities may be 
related to each other according to one-to-many and many-to-one relationships 
(col. 29, lines 46-61, "relationship types have the following attributes... one-to- 
many... many-to-one"). Although the system taught by Zager does not explicitly 
describe the entity-by-entity relationships claimed, it nonetheless suggests, in 
cols. 6 and 29, that entities can have any type of relationship to other entities. 
Thus, it would have been obvious to a person having ordinary skill in the art to 
include the specific one-to-many relationship mentioned in the claim to the 
system taught by Zager, to allow for a more flexible and accurate model of the 
network system. 



In considering claim 16, Bhaskaran further discloses that the virtual IPs 
entities represent virtual IP addresses that are used by a router to route traffic for 
a single IP address to multiple computers (col. 1, lines 52-67). Zager further 
discloses a plurality of monitoring entities (i.e. alarms, etc.) and network entities 
(i.e. routers, etc.). 

In further considering this claim, Zager further discloses that the model 
includes the entities' relationships to each other (col. 6, lines 25-27, "this model 
represents the various components, relevant subcomponents, and their service 
relationships to each other"), and further discloses that the entities may be 
related to each other according to one-to-many and many-to-one relationships 
(col. 29, lines 46-61, "relationship types have the following attributes... one-to- 
many... many-to-one"). Although the system taught by Zager does not explicitly 



Application/Control Number: 09/766,649 Page 
Art Unit: 2153 

describe the entity-by-entity relationships claimed, it nonetheless suggests, in 
cols. 6 and 29, that entities can have any type of relationship to other entities. 
Thus, it would have been obvious to a person having ordinary skill in the art to 
include the specific many-to-one and one-to-many relationships mentioned in the 
claim to the system taught by Zager, to allow for a more flexible and accurate 
model of the network system. 



In considering claim 17, Zager further discloses that the services entities 
represent services to be performed by a series of applications accessible by a 
network server (col. 10, lines 50-60, describing two different client applications 
that access a service at a server). 

In further considering this claim, Zager further discloses that the model 
includes the entities' relationships to each other (col. 6, lines 25-27, "this model 
represents the various components, relevant subcomponents, and their service 
relationships to each other"), and further discloses that the entities may be 
related to each other according to one-to-many and many-to-one relationships 
(col. 29, lines 46-61, "relationship types have the following attributes... one-to- 
many... many-to-one"). Although the system taught by Zager does not explicitly 
describe the entity-by-entity relationships claimed, it nonetheless suggests, in 
cols. 6 and 29, that entities can have any type of relationship to other entities. 
Thus, it would have been obvious to a person having ordinary skill in the art to 
include the specific one-to-many relationship mentioned in the claim to the 
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system taught by Zager, to allow for a more flexible and accurate model of the 
network system. 



In considering claim 18, Zager further discloses that the role 
configurations entities represent configurations related to software roles (col, 6, 
lines 15-28, describing the software components of the models). 

In further considering this claim, Zager further discloses that the model 
includes the entities' relationships to each other (col. 6, lines 25-27, "this model 
represents the various components, relevant subcomponents, and their service 
relationships to each other"), and further discloses that the entities may be 
related to each other according to one-to-many and many-to-one relationships 
(col. 29, lines 46-61, "relationship types have the following attributes... one-to- 
many... many-to-one"). Although the system taught by Zager does not explicitly 
describe the entity-by-entity relationships claimed, it nonetheless suggests, in 
cols. 6 and 29, that entities can have any type of relationship to other entities. 
Thus, it would have been obvious to a person having ordinary skill in the art to 
include the specific many-to-one relationships mentioned in the claim to the 
system taught by Zager, to allow for a more flexible and accurate model of the 
network system. 



In considering claim 19, Zager further discloses that the device role 
configuration entities represent configurations of software roles for specific 
devices (col. 6, lines 15-28). 



Application/Control Number: 09/766,649 Page 
Art Unit: 2153 

In further considering this claim, Zager further discloses that the model 
includes the entities' relationships to each other (col. 6, lines 25-27, "this model 
represents the various components, relevant subcomponents, and their service 
relationships to each other"), and further discloses that the entities may be 
related to each other according to one-to-many and many-to-one relationships 
(col. 29, lines 46-61, "relationship types have the following attributes... one-to- 
many... many-to-one"). Although the system taught by Zager does not explicitly 
describe the entity-by-entity relationships claimed, it nonetheless suggests, in 
cols. 6 and 29, that entities can have any type of relationship to other entities. 
Thus, it would have been obvious to a person having ordinary skill in the art to 
include the specific one-to-many and many-to-one relationships mentioned in the 
claim to the system taught by Zager, to allow for a more flexible and accurate 
model of the network system. 



In considering claim 20, Zager further discloses that status entities 
represent status conditions of various hardware and software objects (i.e. alarms, 
events, etc.). 

In further considering this claim, Zager further discloses that the model 
includes the entities' relationships to each other (col. 6, lines 25-27, "this model 
represents the various components, relevant subcomponents, and their service 
relationships to each other"), and further discloses that the entities may be 
related to each other according to one-to-many and many-to-one relationships 
(col. 29, lines 46-61, "relationship types have the following attributes... one-to- 
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many... many-to-one"). Although the system taught by Zager does not explicitly 
describe the entity-by-entity relationships claimed, it nonetheless suggests, in 
cols. 6 and 29, that entities can have any type of relationship to other entities. 
Thus, it would have been obvious to a person having ordinary skill in the art to 
include the specific one-to-many relationships mentioned in the claim to the 
system taught by Zager, to allow for a more flexible and accurate model of the 
network system. 



In considering claim 21 , Zager further discloses that the component type 
entities represent types of components used with said model (col. 6, lines 12-28). 

In further considering this claim, Zager further discloses that the model 
includes the entities' relationships to each other (col. 6, lines 25-27, "this model 
represents the various components, relevant subcomponents, and their service 
relationships to each other"), and further discloses that the entities may be 
related to each other according to one-to-many and many-to-one relationships 
(col. 29, lines 46-61 , "relationship types have the following attributes... one-to- 
many... many-to-one"). Although the system taught by Zager does not explicitly 
describe the entity-by-entity relationships claimed, it nonetheless suggests, in 
cols. 6 and 29, that entities can have any type of relationship to other entities. 
Thus, it would have been obvious to a person having ordinary skill in the art to 
include the specific one-to-many relationship mentioned in the claim to the 
system taught by Zager, to allow for a more flexible and accurate model of the 
network system. 



Application/Control Number: 09/766,649 



Art Unit: 2153 



Page 



In considering claim 22, Zager further discloses that the device role 
configuration values entities represent configuration values associated with 
software roles of a specific device (col. 6, lines 12-28, wherein a configuration 
necessarily is associated with some value). 

In further considering this claim, Zager further discloses that the model 
includes the entities' relationships to each other (col. 6, lines 25-27, "this model 
represents the various components, relevant subcomponents, and their service 
relationships to each other"), and further discloses that the entities may be 
related to each other according to one-to-many and many-to-one relationships 
(col. 29, lines 46-61, "relationship types have the following attributes... one-to- 
many... many-to-one"). Although the system taught by Zager does not explicitly 
describe the entity-by-entity relationships claimed, it nonetheless suggests, in 
cols. 6 and 29, that entities can have any type of relationship to other entities. 
Thus, it would have been obvious to a person having ordinary skill in the art to 
include the specific many-to-one relationship mentioned in the claim to the 
system taught by Zager, to allow for a more flexible and accurate model of the 
network system. 

Conclusion 

The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 
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